RSI Diff Bot; head commit b601750 merging into b92f5dc
This PR makes changes to 1 or more RSIs. Here is a summary of all changes:

Resources/Textures/Interface/Actions/actions_ai.rsi

State	Old	New	Status
warp			Added

Alternative PR adding this functionality: #31653
Also requesting @Errant-4 for review as the author of the other PR.

This is good quality-of-life for the AI player but I worry this might also be a significant buff. The AI needing to manually scroll around the station means antagonists can "distract" the AI by giving orders or causing problems that direct the AI's attention away from where their actual objective is; letting the AI instantly snap to certain locations improves their response time significantly and makes it very hard to avoid their attention.

This is good quality-of-life for the AI player but I worry this might also be a significant buff. The AI needing to manually scroll around the station means antagonists can "distract" the AI by giving orders or causing problems that direct the AI's attention away from where their actual objective is; letting the AI instantly snap to certain locations improves their response time significantly and makes it very hard to avoid their attention.

This is a seperate issue that should be addressed in a seperate way. AI helping security is primarly due to the fact it is a force that the crew can 100% trust. This can be solved, for example, by allowing ion storms, a malf AI antagonist or natural tools allowing you to deter an AI from a location (disabling cameras, specific items to become invisible to silicons, similiar)
Rejecting what is essentially a huge QoL feature should not be done on a basis that a role that has nothing better to do does the only thing it can do, instead AI should be expanded so it has a natural role on the station outside of "I just spectate but can also talk".
Also unfortunately, all changes that fix this sorta behaviour are also in need of a silicon/AI design document

Gonna be honest, my first reaction was to be "territorial", and biased toward my own solution. Perhaps natural. But on some reflection, I don't really care if I'm the one who gets the feature in or not, so long as it's done. I do not own this idea, and I also have other stuff I should be working on, too, so being able to "outsource" this is a net gain for the project, I suppose. Feel free to use any part of #31653 if you want

I did not do an in-depth code review but the biggest difference that immediately stood out to me is that this one works through just clicking on the map. I chose not to do that so it does not overlap with the current functionality, though this is undeniably more intuitive - would people reliably find how to navmap warp with my version?

As mentioned above, the hurdle that needs to be coded is that you need to do something like ViewSubscriber, but for coordinates instead of to an entity. This functionality is not yet coded.
The simplest way to achieve this would be to create/teleport an invisible intangible dummy entity, and viewsubscribe to that. Maintainer opinion differs whether this should be put into the engine in ViewSubscriberSystem, or can just be in the middle of the warp code. If it will just be put into content, please compartmentalize it into a distinct function so it will be fully portable for a later move to engine